Welcome back to the lecture.

What did we do last week?

We just briefly talked about it during the exercise or during the tutorial already.

That we looked at the security proof for the construction of unidirectional

radiative key exchange that we introduced one week earlier than that.

And for the definition that we introduced even two weeks before that.

And that's somewhat the peak of complexity for the entire lecture series.

It is somewhat, it should have given you an idea of how to prove such complicated,

complex protocols with tools that we learned throughout the previous lectures.

For a tool that could be used in real world messaging protocols, but since we just considered

a very small fraction of a real messaging protocol, in particular we just looked at

unidirectional communication, we just looked at continuous key exchange, so we didn't look at

message encryption, we didn't look at interaction between Alice and Bob,

where also Bob contributes new information to Alice and so on.

So we removed a lot of complexity to just focus on a small building block, but still

the proof was doable and hopefully also comprehensible within one lecture.

For the remaining few lectures that we have until the end of the semester,

we will look at other building blocks that are helpful, relevant and interesting in the

messaging context, but for none of them we will introduce or look at formal security

proofs, because the security proofs are typically more complicated, we can't fit them into a

lecture and they won't give you much more, I don't know, intuition for how to prove security

for such things. Instead what we do, for example starting today, is, so we briefly did that in

last week's lecture and exercise already, we look at weak randomness as a threat vector.

As a threat vector.

And what we seen last week is that under weak randomness this construction of unidirectional

right-handed key exchange for which we proved that it is secure as long as randomness is good

is, so we saw that as long as randomness is good we even proved that it is secure, but as long as

as soon as when randomness is bad we see that this construction becomes insecure.

And there are different ways how to handle that, either we just assume or think that weak randomness

is not a threat at all, but we will see there are a couple of reasons why weak randomness should

be considered. And instead what we then do in the second step today is we look at a building block

that could help us or that helps us actually provably to enhance this unidirectional right-handed

key exchange construction such that it becomes secure even under weak randomness. So it is

strongly secure according to that definition even if we allow the adversary furthermore to reveal or

even modify or determine the random coins that the sender is using. And this building block that we

look at is called key updatable key encapsulation mechanism. We will look at two different construction

ideas of how to build key encapsulation or key updatable key encapsulation mechanisms

and depending on the time we will then look at the double ratchet.

So in the exercise today we briefly went into looking how far parts of the double ratchet fit

into our formalization of unidirectional ratchet key exchange, how far this offers security,

but and we had a high level overview of what the double ratchet does when we also look at

bi-directional interaction. But yeah this will be a very short video, but I hope you enjoyed it.

But yeah this will be something that we will do at the end of today's lecture.

Okay so first of all what we observed is that unidirectional ratchet key exchange

under weak randomness

is a problem. So why is that a problem? First of all the motivation.

Why is it a threat? So first of all we talked about this last week already. There are situations

in which the devices that we use didn't gather enough randomness, enough entropy to

be a good seed for key generation for example or for anything else that we use randomness for.

So the first problem could be that there is too